[LG-5532] feat(time-input): Segment state utils #3385

shaneeza · 2025-12-15T14:37:25Z

✍️ Proposed changes

This PR introduces utility functions for managing time input segment state, including validation, formatting, and conversion between 12-hour and 24-hour formats. The implementation handles timezone conversions, segment validation, and provides comprehensive test coverage.

This PR is the third PR in a chain of PRs

🧪 How to test changes

…efault handling

…omponents with context integration

…tate handling in TimeInputInputs component

…segment rules and default values

… support 12/24 hour formats

…cale dependency and enhancing formatting logic

… format output with and without seconds

…meInputDisplayContext

…xt handling

…kMode and size, and add console log for debugging in TimeInputInputs

…omponent, covering rendering, value updates, and keyboard interactions

…12HourFormat prop, replacing TimeSegments with TimeSegment for improved clarity and consistency

…ity in time input context

… stories

… pnpm-lock.yaml

…rmatting logic

… in TimeInputSegment tests

…t for clarity

…db/leafygreen-ui into LG-5538/segments-parse-time

…ygreen-ui into LG-5532/segments-display-values

stephl3

finished reviewing the latter half of the PR, but still reviewing more 🫡

stephl3 · 2025-12-23T19:34:41Z

packages/time-input/src/utils/shouldSetValue/shouldSetValue.ts

+import { isEverySegmentFilled } from '../isEverySegmentFilled/isEverySegmentFilled';
+import { isEverySegmentValueExplicit } from '../isEverySegmentValueExplicit/isEverySegmentValueExplicit';


Suggested change

import { isEverySegmentFilled } from '../isEverySegmentFilled/isEverySegmentFilled';

import { isEverySegmentValueExplicit } from '../isEverySegmentValueExplicit/isEverySegmentValueExplicit';

import { isEverySegmentFilled } from '../isEverySegmentFilled';

import { isEverySegmentValueExplicit } from '../isEverySegmentValueExplicit';

stephl3 · 2025-12-23T20:14:48Z

packages/time-input/src/utils/isEverySegmentFilled/isEverySegmentFilled.ts

+export const isEverySegmentFilled = (segments: TimeSegmentsState) => {
+  const isEverySegmentFilled = Object.values(segments).every(segment => {
+    const isSegmentDefined = isDefined(segment);
+    const isSegmentEmpty = segment === '';
+    return !isSegmentEmpty && isSegmentDefined;
+  });
+  // check if all segments are not empty
+  return isEverySegmentFilled;
+};


The values of an object that has a type of TimeSegmentsState will always be strings, so this could be simplified to:
const isEverySegmentFilled = Object.values(segments).every(segment => segment !== '');

Also worth considering if it's still necessary to have a util at that point

I'd like to keep this for now and reevaulate in the next PR in this chain that uses it

stephl3 · 2025-12-23T20:19:56Z

packages/time-input/src/utils/isEverySegmentValid/isEverySegmentValid.ts

+        segment: segment as TimeSegment,
+        value: value as string,


are these type assertions necessary?

ahh I see Object.entries() is expanding the types to be strings. I think it'd make more sense to move the assertion to that line so it propagates to these later lines. something like:
(Object.entries(segments) as Array<[TimeSegment, string]>)

stephl3 · 2025-12-23T20:29:33Z

packages/time-input/src/utils/isEverySegmentValid/isEverySegmentValid.ts

+        defaultMin: getDefaultMin({ is12HourFormat })[segment as TimeSegment],
+        defaultMax: getDefaultMax({ is12HourFormat })[segment as TimeSegment],


nit: can optimize this by creating the initial objects for defaultMinValues and defaultMaxValues outside of the loop

stephl3 · 2025-12-23T20:33:56Z

packages/time-input/src/utils/isEverySegmentValueExplicit/isEverySegmentValueExplicit.ts

+  segments: TimeSegmentsState;
+  is12HourFormat: boolean;
+}): boolean => {
+  return Object.entries(segments).every(([segment, value]) => {


similar note as above about asserting types when using Object.entries()

stephl3 · 2025-12-23T20:34:34Z

packages/time-input/src/utils/isEverySegmentValueExplicit/isEverySegmentValueExplicit.ts

+import { TimeSegment, TimeSegmentsState } from '../../shared.types';
+import { getTimeSegmentRules } from '../getTimeSegmentRules';
+
+export const isExplicitSegmentValue = (is12HourFormat: boolean) =>


The name of this helper sounds like it would return a boolean. Maybe createExplicitTimeSegmentValidator is more appropriate?

stephl3 · 2025-12-23T20:45:46Z

packages/time-input/src/utils/isEverySegmentValueExplicit/isEverySegmentValueExplicit.spec.ts

+    describe('hour', () => {
+      describe('returns false', () => {
+        test('if hour is 0', () => {


nit: could accept the mild duplication trade-off and flatten this for readability

Suggested change

describe('hour', () => {

describe('returns false', () => {

test('if hour is 0', () => {

describe('hour segment', () => {

test('returns false when hour is 0', () => {

stephl3 · 2025-12-23T20:49:08Z

packages/time-input/src/utils/isEverySegmentValueExplicit/isEverySegmentValueExplicit.spec.ts

+      describe('returns true', () => {
+        describe('when single digit and value is greater than or equal to the min explicit value (2)', () => {
+          test.each(range(2, 10))('%i', i => {


similarly for this:

Suggested change

describe('returns true', () => {

describe('when single digit and value is greater than or equal to the min explicit value (2)', () => {

test.each(range(2, 10))('%i', i => {

test.each('returns true for single digit hour %i', () => {

won't continue repeating feedback but similarly for the later blocks, I think it would help readability to flatten or block these with conditions or labels as opposed to assertion statements

stephl3 · 2025-12-23T20:53:06Z

packages/time-input/src/utils/shouldSetValue/shouldSetValue.ts

+  // If the date is valid and all segments are explicit, then the value should be set.
+  const isValidDateAndSegmentsAreExplicit =


This could just be me, but comments like this seem redundant because it re-states the variable name in sentence format

makes sense

… up imports in shouldSetValue

…ment handling and improving type safety

…TimeSegmentValidator for clarity and update its usage in isEverySegmentValueExplicit

stephl3 · 2025-12-23T20:59:46Z

packages/date-utils/src/index.ts

 export { isSameTZDay } from './isSameTZDay';
 export { isSameTZMonth } from './isSameTZMonth';
 export { isSameUTCDay } from './isSameUTCDay';
+export { isSameUTCDayAndTime } from './isSameUTCDayAndTime';


haven't been looking for it for time-input but do changes to date-utils need a changeset?

yes! I was planning on adding all changesets related to the segment integration in a separate PR

stephl3 · 2025-12-23T21:00:16Z

packages/date-utils/src/isSameUTCDay/isSameUTCDay.spec.ts

 import { isSameUTCDay } from '.';

-const TZOffset = -5;
+const timeZone = 'America/New_York';


nit: would more explicitly name this constant

stephl3 · 2025-12-23T21:03:32Z

packages/date-utils/src/isSameUTCDay/isSameUTCDay.spec.ts

+      // September 9, 2023 21:00 EDT
+      const local = newTZDate({
+        timeZone,
+        year: 2023,
+        month: 8,
+        date: 9,
+        hours: 21,
+      }); // September 10, 2023 01:00 UTC


while making these changes to these tests, it could be helpful to rewrite the test statements because they're quite confusing currently since they just say "returns true" and "returns false"

stephl3 · 2025-12-23T21:04:54Z

packages/date-utils/src/isSameUTCMonth/isSameUTCMonth.spec.ts

 describe('packages/date-utils/isSameUTCMonth', () => {
  beforeEach(() => {
-    mockTimeZone('America/New_York', TZOffset);
+    mockTimeZone(timeZone, TZOffset);


similarly, for these tests, it could be beneficial to add context to the test statements that currently only state boolean values

stephl3 · 2025-12-23T21:08:20Z

packages/date-utils/src/isSameUTCDayAndTime/isSameUTCDayAndTime.ts

+ * @param day2 - The second date to check
+ * @returns Whether the two dates are the same day and time in UTC
+ */
+export const isSameUTCDayAndTime = (


maybe isSameUTCDateTime since we're comparing DateType?

stephl3 · 2025-12-23T21:13:53Z

packages/time-input/src/TimeInputInputs/TimeInputInputs.tsx

     */
    const { selectUnit, setSelectUnit } = useSelectUnit({
-      dayPeriod: timeParts.dayPeriod,
+      dayPeriod: timeParts.dayPeriod as DayPeriod,


I understand most date time parts being string types since they are input fields, but have you considered making dayPeriod strictly a DayPeriod so you don't have to include this type assertion?

stephl3 · 2025-12-23T21:49:58Z

packages/time-input/src/utils/doesSomeSegmentExist/doesSomeSegmentExist.ts

+ * @param segments - The segments to check
+ * @returns Whether some segment exists
+ */
+export const doesSomeSegmentExist = (segments: TimeSegmentsState) => {


This duplicates isEverySegmentFilled at this point, so we should consolidate

stephl3 · 2025-12-23T21:53:20Z

packages/time-input/src/utils/findUnitOptionByDayPeriod/findUnitOptionByDayPeriod.ts

+    option => option.displayName === dayPeriod,
+  );
+
+  return selectUnitOption ?? unitOptions[0];


is there a reason why it it's possibly not found? feels like there's something else to update to prevent that from being possible

Array.find() return type is T | undefined even though we know that it shouldn't return undefined so we're just adding a fallback.

If we update the type of UnitOptions to use DayPeriod for it's object values, it should be safe to assert that a value is always found and simplify this to:
return unitOptions.find(option => option.displayName === dayPeriod)!;

That is true. In this case, it will always be one of the options.

stephl3 · 2025-12-23T21:57:36Z

packages/time-input/src/utils/getNewUTCDateFromSegments/getNewUTCDateFromSegments.ts

+  dateValues: {
+    day: string;
+    month: string;
+    year: string;
+  };


is there an existing type for this?

stephl3 · 2025-12-23T21:59:56Z

packages/time-input/src/utils/getNewUTCDateFromSegments/getNewUTCDateFromSegments.ts

+  /**
+   * Check if all segments are filled and valid (not necessarily explicit). If they are, return the UTC date.
+   */
+  if (
+    isEverySegmentFilled(segments) &&
+    isEverySegmentValid({ segments, is12HourFormat })
+  ) {
+    return newTZDate({
+      year: Number(year),
+      month: Number(month) - 1,
+      date: Number(day),
+      hours: Number(converted12hTo24hHour),
+      minutes: Number(minute),
+      seconds: Number(second),
+      timeZone,
+    });
+  }
+
+  /**
+   * Check if any segments are filled. If not, return null. This means all segments are empty.
+   */
+  if (!doesSomeSegmentExist(segments)) {
+    return null;
+  }
+
+  /**
+   * Return an invalid date object if some segments are empty or invalid.
+   */
+  return new Date('invalid');


Since isEverySegmentFilled and doesSomeSegmentExist are the same, I think this can be approached differently. Also, I think it will be more readable if some condition leads to an early return of an invalid date, and the final return is return newTZDate(...);

They're different. isEverySegmentFilled checks that all segments are filled, while doesSomeSegmentExist checks if at least one segment is filled.

We need to check if all segments are empty. If they are, then we return null, so we use doesSomeSegmentExist for this check. It will return true if at least one segment is filled. We can't use isEverySegmentFilled because it will return false if at least one segment is empty. There is a chance that the other segments can be filled.

We also need to check if every segment is filled. That's when we use isEverySegmentFilled. We can't use doesSomeSegmentExist because that will return true as soon as one segment is filled. So there is a chance that the other segments can be empty.

I get confused easily with every and some, so I hope this explanation makes sense. If not, happy to jump on a call.

Ahh yeah, I see that they use a different method. My b!

…eExplicit tests for clarity and consistency

…ce getNewUTCDateFromSegments logic for better clarity

…and adjust related logic in TimeInputInputs and getFormattedDateTimeParts

…t handling and update getNewUTCDateFromSegments to utilize it

…ec for improved readability and consistency

…proving comments and consistency in date conversions

… by renaming timeZone variable for clarity

…rity across various utility tests

…and isSameUTCMonth.spec for better clarity and consistency

… across components

stephl3 · 2025-12-30T20:02:56Z

packages/time-input/src/utils/findUnitOptionByDayPeriod/findUnitOptionByDayPeriod.ts

+    option => option.displayName === dayPeriod,
+  );
+
+  return selectUnitOption ?? unitOptions[0];


If we update the type of UnitOptions to use DayPeriod for it's object values, it should be safe to assert that a value is always found and simplify this to:
return unitOptions.find(option => option.displayName === dayPeriod)!;

stephl3 · 2025-12-30T20:07:38Z

packages/time-input/src/shared.types.ts

+  [DateTimePartKeys.dayPeriod]: DayPeriod;
+};
+
+export type DateParts = Pick<DateTimeParts, 'day' | 'month' | 'year'>;


Instead of creating another DateParts type, I was actually wondering if there was an existing one in one of the other date/time-related packages. It looks like there is DateSegment but it's in the date-picker package. It'd be ideal to centralize some types in a shared package like date-utils or input-box. It would keep things more DRY

Interesting. I like this idea, but I want to think it through a little more on where it should be placed and what should be included. I can create a ticket for this.

stephl3 · 2025-12-30T20:07:58Z

packages/time-input/src/utils/getNewUTCDateFromSegments/getNewUTCDateFromSegments.ts

+  /**
+   * Check if all segments are filled and valid (not necessarily explicit). If they are, return the UTC date.
+   */
+  if (
+    isEverySegmentFilled(segments) &&
+    isEverySegmentValid({ segments, is12HourFormat })
+  ) {
+    return newTZDate({
+      year: Number(year),
+      month: Number(month) - 1,
+      date: Number(day),
+      hours: Number(converted12hTo24hHour),
+      minutes: Number(minute),
+      seconds: Number(second),
+      timeZone,
+    });
+  }
+
+  /**
+   * Check if any segments are filled. If not, return null. This means all segments are empty.
+   */
+  if (!doesSomeSegmentExist(segments)) {
+    return null;
+  }
+
+  /**
+   * Return an invalid date object if some segments are empty or invalid.
+   */
+  return new Date('invalid');


Ahh yeah, I see that they use a different method. My b!

…lidating enums and improving type usage

github-actions · 2025-12-30T22:33:14Z

Coverage after merging LG-5532/segments-state-utils into shaneeza/segment-logic-integration will be

79.22%

Coverage Report for Changed Files

File	Stmts	Branches	Funcs	Lines	Uncovered Lines
packages/date-utils/src/isSameUTCDateTime
isSameUTCDateTime.ts	100%	100%	100%	100%
packages/date-utils/src/newTZDate
newTZDate.ts	85.71%	71.43%	100%	100%	36, 58
packages/time-input/src
constants.ts	100%	100%	100%	100%
packages/time-input/src/TimeInputInputs
TimeInputInputs.tsx	0%	0%	0%	0%	19, 21–22, 24–25, 31, 37, 43, 53, 59, 68, 72, 72, 76, 86
packages/time-input/src/TimeInputSelect
TimeInputSelect.tsx	94.44%	50%	100%	100%	38
packages/time-input/src/hooks/useSelectUnit
useSelectUnit.ts	0%	0%	0%	0%	19, 23–24, 26, 37, 46–47, 49, 51, 51, 51–53, 57
packages/time-input/src/utils/convert12hTo24h
convert12hTo24h.ts	100%	100%	100%	100%
packages/time-input/src/utils/doesSomeSegmentExist
doesSomeSegmentExist.ts	100%	100%	100%	100%
packages/time-input/src/utils/getFormatPartsValues/getFormattedDateTimeParts
getFormattedDateTimeParts.ts	93.33%	75%	100%	100%	43
packages/time-input/src/utils/getNewUTCDateFromSegments
getNewUTCDateFromSegments.ts	100%	100%	100%	100%
packages/time-input/src/utils/getPaddedTimeSegmentsFromDate
getPaddedTimeSegmentsFromDate.ts	100%	100%	100%	100%
packages/time-input/src/utils/getPaddedTimeSegmentsFromDate/getPaddedTimeSegments
getPaddedTimeSegments.ts	100%	100%	100%	100%
packages/time-input/src/utils/isEverySegmentValueExplicit
isEverySegmentValueExplicit.ts	100%	100%	100%	100%
packages/time-input/src/utils/shouldSetValue
shouldSetValue.ts	100%	100%	100%	100%

shaneeza added 30 commits November 26, 2025 12:11

feat(time-input): add utils for toggling select and formatparts

bf86e07

wip

612b474

refactor(time-input): enhance time formatting utilities and improve d…

a578ecb

…efault handling

refactor(time-input): improve time input handling and formatting logic

804cd88

feat(time-input): add TimeFormField and TimeFormFieldInputContainer c…

1db42af

…omponents with context integration

temp remove ts check

206e145

refactor(time-input): clean up unused select unit logic and improve s…

bb3916d

…tate handling in TimeInputInputs component

feat(time-input): enhance TimeInput component with new constants for …

df69d22

…segment rules and default values

refactor(time-input): update time segment rules and default values to…

2f5707f

… support 12/24 hour formats

refactor(time-input): simplify getFormatParts function by removing lo…

9715407

…cale dependency and enhancing formatting logic

test(time-input): add unit tests for getFormatParts utility to verify…

dad7b62

… format output with and without seconds

refactor(time-input): remove locale dependency from formatParts in Ti…

f559593

…meInputDisplayContext

feat(time-input): add default time parts and enhance time input conte…

3e6f6be

…xt handling

merge conflits

1ef4c97

feat(time-input): enhance TimeInput stories with new argTypes for dar…

87023fb

…kMode and size, and add console log for debugging in TimeInputInputs

test(time-input): add comprehensive unit tests for TimeInputSegment c…

580c90f

…omponent, covering rendering, value updates, and keyboard interactions

test(time-input): add comprehensive unit tests for TimeInputSegment c…

2495aa1

…omponent, covering rendering, value updates, and keyboard interactions

refactor(time-input): update time segment handling to use explicit is…

4cad730

…12HourFormat prop, replacing TimeSegments with TimeSegment for improved clarity and consistency

refactor(time-input): rename shouldShowSelect to is12hFormat for clar…

1afe57e

…ity in time input context

refactor(time-input): clean up unused state and comments in TimeInput…

cb84996

… stories

chore(pnpm-lock): add workspace links for @leafygreen-ui/input-box to…

6e265a7

… pnpm-lock.yaml

refactor(time-input): remove unused console logs and simplify time fo…

2547fdc

…rmatting logic

merge conflict

10d4039

refactor(time-input): clean up comments and improve test descriptions…

e46a73c

… in TimeInputSegment tests

refactor(time-input): remove outdated TODO comment in TimeInputContex…

94ed98f

…t for clarity

merge conflict

7e42f34

Merge branch 'shaneeza/segment-logic-integration' of github.com:mongo…

2d2fbd5

…db/leafygreen-ui into LG-5538/segments-parse-time

Merge branch 'LG-5538/segments-parse-time' of github.com:mongodb/leaf…

d9b99ec

…ygreen-ui into LG-5532/segments-display-values

merge conflict

f07a1b8

test(time-input): add unit tests for TimeInputBox component

ed87ee7

shaneeza requested a review from tsck December 23, 2025 15:29

merge conflict

bf03d5f

shaneeza removed the request for review from tsck December 23, 2025 15:44

shaneeza added 2 commits December 23, 2025 10:49

testing

644288d

revert

d818cba

stephl3 reviewed Dec 23, 2025

View reviewed changes

shaneeza added 3 commits December 23, 2025 16:25

refactor(time-input): simplify isEverySegmentFilled utility and clean…

be44130

… up imports in shouldSetValue

refactor(time-input): enhance validation utilities by simplifying seg…

451b0ea

…ment handling and improving type safety

refactor(time-input): rename isExplicitSegmentValue to createExplicit…

2a4ffd3

…TimeSegmentValidator for clarity and update its usage in isEverySegmentValueExplicit

stephl3 reviewed Dec 23, 2025

View reviewed changes

shaneeza added 12 commits December 23, 2025 17:22

refactor(time-input): improve test descriptions in isEverySegmentValu…

10fb946

…eExplicit tests for clarity and consistency

refactor(time-input): simplify doesSomeSegmentExist utility and enhan…

b0726e0

…ce getNewUTCDateFromSegments logic for better clarity

refactor(time-input): update DateTimeParts type to include dayPeriod …

06ee1ef

…and adjust related logic in TimeInputInputs and getFormattedDateTimeParts

refactor(time-input): introduce DateParts type for better date segmen…

b11b0ec

…t handling and update getNewUTCDateFromSegments to utilize it

refactor(date-utils): streamline test cases in isSameUTCDayAndTime.sp…

055f87c

…ec for improved readability and consistency

refactor(date-utils): enhance test clarity in isSameUTCDay.spec by im…

dd11802

…proving comments and consistency in date conversions

refactor(date-utils): improve test consistency in isSameUTCMonth.spec…

85e285e

… by renaming timeZone variable for clarity

refactor(time-input): enhance test descriptions and structure for cla…

3399988

…rity across various utility tests

refactor(date-utils): improve test descriptions in isSameUTCDay.spec …

18e30a2

…and isSameUTCMonth.spec for better clarity and consistency

refactor(date-utils): rename isSameUTCDayAndTime to isSameUTCDateTime

5682f66

refactor(date-utils): update exports and tests for isSameUTCDateTime

17210c4

refactor(time-input): consolidate unit option types and improve usage…

4ab1e7d

… across components

shaneeza requested a review from stephl3 December 30, 2025 00:08

stephl3 reviewed Dec 30, 2025

View reviewed changes

refactor(time-input): enhance time and date segment handling by conso…

58fcac0

…lidating enums and improving type usage

shaneeza requested a review from stephl3 December 30, 2025 22:09

stephl3 approved these changes Dec 30, 2025

View reviewed changes

shaneeza merged commit 753fca9 into shaneeza/segment-logic-integration Dec 31, 2025
12 of 14 checks passed

shaneeza deleted the LG-5532/segments-state-utils branch December 31, 2025 15:40

		import { isEverySegmentFilled } from '../isEverySegmentFilled/isEverySegmentFilled';
		import { isEverySegmentValueExplicit } from '../isEverySegmentValueExplicit/isEverySegmentValueExplicit';

		defaultMin: getDefaultMin({ is12HourFormat })[segment as TimeSegment],
		defaultMax: getDefaultMax({ is12HourFormat })[segment as TimeSegment],

		// If the date is valid and all segments are explicit, then the value should be set.
		const isValidDateAndSegmentsAreExplicit =

[LG-5532] feat(time-input): Segment state utils #3385

[LG-5532] feat(time-input): Segment state utils #3385

Uh oh!

Conversation

shaneeza commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✍️ Proposed changes

🧪 How to test changes

Uh oh!

stephl3 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shaneeza Dec 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shaneeza commented Dec 15, 2025 •

edited

Loading

shaneeza Dec 23, 2025 •

edited

Loading